Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP09。

提案寫出來了，並不代表它已經是規則。

上一篇讓 AI 在任務結束後自動產出改善提案。但如果這些提案「寫完就直接生效」，其實很危險——AI 寫得再完整、再有條理，也不代表這段經驗適用於整個團隊，也可能只是碰巧在某個特殊情境下有效。

所以我們刻意加了一道治理閘門：所有回顧產出的提案，狀態都是 proposed（僅供審查），必須經過人工挑選，才能升格成 promoted（正式規則）。

unreviewed → proposed → promoted
                └──────→ 被拒絕，回頭修改或直接丟棄

# 列出本次待審查的提案，並且可以選擇核准全部或指定編號
.\scripts\approve-retrospective-items.ps1

腳本列出來的每一條，預設都還只是提案。

沒有人點頭之前，它們不會進入共用的規則。

這個設計其實兼顧了兩件事：

1. 速度：日常任務不需要卡在審查上，AI 可以先把發現寫下來，不用等審核完才能收工。
2. 品質：只有真的值得長期保留的內容，才會真正進到大家每天都會讀到的共用規則裡。

換句話說，AI 負責發現與草擬，人負責判斷與拍板。

這條界線一旦模糊——比如讓 AI 自己審查自己的提案——整套系統很快就會被一次性、局部有效的經驗污染，變成誰的 AI 話比較多聲音就比較大。

這加起來其實就一句話：
經驗可以先寫下來，但能不能變成大家每天都要遵守的規則，必須由人來拍板。

有了審查機制，接下來的問題是：這麼多規則、這麼多入口，人跟 AI 到底該從哪裡開始讀？

下一篇來聊。